Nowadays, complex computing tasks are typically processed by complex software programs, wherein such software is typically organized in multiple modules, each being in charge of a certain processing. One way of implementing such a system in the programming language Java is provided by a dynamic and modularized architecture model called OSGi (Open Services Gateway initiative; cf. http://en.wikipedia.org/wiki/OSGi). OSGi is a module system and service platform for the Java programming language implementing functional components in the form of bundles and services in an OSGi environment. OSGi services are Java object instances, registered into the OSGi framework. Any Java object can be registered as a service, but typically it implements a well-known interface. OSGi bundles can be used to group one or more OSGi services and are typically specified as jar components with extra manifest headers. The functional components (i.e. bundles and services) are typically managed using a service registry of the respective OSGi environment. Accordingly, using OSGi technology, a given software program can be better structured into distinct bundles and services which invoke each other during runtime. Still, a given OSGi environment is a self-contained system running within one instance of a Java Virtual Machine (JVM) on a single computer.
Along with the increasing demand on processing power, it is however desirable that complex processing tasks are executed in a physically distributed computing system, in which multiple OSGi environments communicate with each other. In other words, it is oftentimes desired that one given OSGi environment is enabled to call services provided by another, i.e. remote, OSGi environment (which might be located on the same computer, but also on a different computer connected over a network, such as the Internet). High throughput data (e.g. a huge amount of messages) typically has to be communicated in such distributed systems in a reasonable time frame. Referring to the internet network example above, an OSGi system has to be accordingly distributed to different OSGi environments. It is indispensable to manage the communication of messages in such a OSGi network (or distributed system) in a usable and effectively high throughput manner.
The OSGi platform provides a solution for distributed environments, namely Remote OSGi (R-OSGi) services. In the publication “Services Everywhere: OSGi in Distributed Environments” of Rellermeyer et al. (cf. http://people.inf.ethz.ch/rjan/publications/rellermeyer_eclipsecono7.pdf) the basic design principles of R-OSGi, such as transparent service access, interaction, internal structures and techniques used in R-OSGi are disclosed. Typically each R-OSGi comprises a TCP-Channel for one-to-one TCP connection with another R-OSGi.
In this prior art approach and system (hereinafter also referred to as “Classic R-OSGi TCP/IP transport”) the network comprises OSGi environments as nodes, preferably Remote OSGi (illustrated in FIG. 1 and disclosed in the publication of Rellermeyer et al.), and messages are communicated between the nodes via TCP connections as edges.
As shown in FIG. 1, in this classical system for managing communication between a plurality of Open Services Gateway initiative (OSGi) environments, each OSGi environment has to be connected to all other OSGi environments leading to an exponential number of connections (one-to-one TCP connection). This is particularly disadvantageous, since this architecture not only requires vast amounts of network communication, but also since each participating OSGi environment has to keep track of which other OSGi environments are available within the network. One further disadvantage arises when a new OSGi environment is added to the network. In this case, connections to all the other OSGi environments have to be set up. Another disadvantage is the requirement to use multicast (or multiplexed broadcast) connections. Although the standard R-OSGi technology is based on multicast, multicast is typically forbidden on most networks. For example, multicast does not work in many cloud environments, which is a limiting factor.
Therefore, those skilled in the art will appreciate that managing communication in huge OSGi networks is a complex and difficult task, while severe effects can arise if the data transfer does not work as expected.
EP patent application publication no. 2088741 A1 discloses a method and OSGi bundle for sharing a local service on an embedded device. Further it is disclosed that the embedded device comprises communication means for communication between connected devices. For example a home network comprising a plurality of interconnected devices is mentioned in this application publication. This method can be applied on service frameworks, comprising OSGi. Certain communication protocols e.g. used by R-OSGi can be integrated.
Further the publication “Clustering OSGi Applications using Distributed Shared Memory” of Gelibert at al. (http://en.youscribe.com/catalogue/reports-and-theses/professional-resources/it-systems/clustering-osgi-applications-using-distributed-shared-memory-1693585) discloses an approach for integrating a distributed shared memory (DSM). DSM is integrated into the OSGi service platform for the distribution and clustering of OSGi services.
However, while the above-discussed prior art systems and approaches allow for a distribution of systems and communicating messages using R-OSGi, the proposed prior art approached still lack the important ability of managing the data transfer of messages efficiently.
It is therefore the technical problem underlying certain example embodiments to provide a system for managing communication between a plurality of Open Services Gateway initiative (OSGi) environments in such a manner that communication can be managed efficiently in terms of reduction of connections, network traffic and management effort, thereby at least partly overcoming the above explained disadvantages of the prior art.
This problem is according to one aspect solved by a system for managing communication between a plurality of Open Services Gateway initiative (OSGi) environments. In the embodiment of claim 1, the system comprises:    a. a messaging broker, adapted for receiving a message from one of the OSGi environments, wherein the message comprises a call of a service provided by one of the other OSGi environments, and further adapted for transferring the message to the other OSGi environment;    b. wherein the plurality of OSGi environments communicate only via the messaging broker.
Accordingly, the embodiment defines a distributed OSGi system or network with a plurality of interconnected OSGi environments. Importantly the system for managing communication between OSGi environments comprises an additional messaging broker as central system component. The messaging broker is adapted to receive messages from the OSGi environments and to transfer a received message to the intended other OSGi environment(s). Such messages may comprise a call of a service provided by one of the other OSGi environments. Importantly, the prior art disadvantage of one-to-one connections between the OSGi environments is overcome this way by allowing the connection and/or communication among the individual OSGi environments only via the messaging broker. This reduces the number of interconnections to a great extent and enables a faster data transfer in a high throughput fashion.
In another aspect, the messaging broker is adapted for receiving a register request from an OSGi environment to register with the message broker. In response to the register request, the messaging broker may be adapted for providing a unique identifier to the requesting OSGi environment. Accordingly, the OSGi environment(s) may have to register themselves with the messaging broker before sending messages to the messaging broker. Therefore the messaging broker is adapted to receive register requests from the OSGi environments. The OSGi environments can be registered by a unique identifier and/or other features for registration by the messaging broker. This registration may be one possibility to control the management of communicating messages in that for example just registered OSGi environments may be allowed to send messages to the messaging broker and new OSGi environments can be detected upon sending a request to the messaging broker. In other words, having the messaging broker act as a central registration point in the distributed system serves to maintain control about which and/or how many OSGi environment(s) are currently participating in the system at any time.
In yet another aspect, in response to the registering of an OSGi environment, the messaging broker is adapted for notifying all other OSGi environments. Accordingly, the messaging broker is adapted to notify all other OSGi environments if a new OSGi environment has been registered. This notification assures that the other OSGi environments are always up to date, i.e. each OSGi environment always knows which other OSGi environments are currently available within the system. More precisely, the OSGi environments can be informed which OSGi environments are registered and/or these registered OSGi environments can be used for interconnection and/or communicating messages.
Accordingly, the above-mentioned aspects of enabling OSGi environments to register with the messaging broker and to be notified of other OSGi environments essentially establishes an efficient publish/subscribe mechanism. This is another fundamental difference over the point-to-point communication employed in the prior art approach discussed in the introductory part above.
In one aspect, the OSGi environments are adapted for transmitting, via the message broker, a message comprising a list of provided services to at least one other OSGi environment. As mentioned in the introductory part further above, OSGi environments typically comprise at least one service, i.e. a certain well-defined processing component which can invoke other services. In order for one OSGi environment to know which services are provided by other OSGi environments, the OSGi environments may send each other a message which comprises a list of provided services. This message is preferably sent by a given OSGi environment after the OSGi environment has registered with the messaging broker.
In a further aspect, the system comprises an inbox cache for each OSGi environment, wherein the inbox cache is adapted for storing messages comprising a call of a service provided by the respective OSGi environment. Additionally or alternatively, in response to a notification that a new OSGi environment is registered with the messaging broker, each OSGi environment may be adapted for creating an outbox cache for the new OSGi environment, wherein the outbox cache is adapted for storing messages comprising a call of a service provided by the new OSGi environment. Accordingly, cache technology can be advantageously incorporated in the system of certain example embodiments. Two types of caches can be considered, namely an inbox and/or outbox cache. The inbox cache of a given OSGi environment can be applied for storing messages that are directed to that OSGi environment, i.e. messages comprising a call of a service provided by the respective OSGi environment. Further, when a first OSGi environment has set-up an outbox cache for a second OSGi environment, when the first OSGi environment intends to send a message to the second OSGi environment, it simply places the message into the respective outbox cache. It will be appreciated that using the provided cache technology is particularly advantageous, since each OSGi environment simply has to place its messages into the corresponding cache, while the actual transport from the source OSGi environment to the target OSGi environment is handled by the messaging broker, i.e. completely transparent to the involved OSGi environments.
It will be appreciated that the terms “inbox cache” and “outbox cache” are to be understood broadly, in that they only indicate the intended direction in which the respective cache is used. The person skilled in the art will appreciate that alternative terms such as “input buffer”/“output buffer” or “send buffer”/“receive buffer” could similarly be used.
Various embodiments based on cache technology can be considered. For example, the inbox cache and the outbox cache(s) may be stored locally on a computing system of the respective OSGi environment. Alternatively, the inbox cache and the outbox cache associated with a particular OSGi environment may be stored in a single cache, which is preferably stored on the messaging broker.
In a preferred aspect, one of the OSGi environments is adapted for placing a message comprising a call of a service provided by another OSGi environment into an outbox cache associated with the other OSGi environment, wherein the messaging broker is adapted for transferring the message from the outbox cache associated with the other OSGi environment to an inbox cache of the other OSGi environment, and wherein the messaging broker is adapted for notifying the other OSGi environment of the new message in the inbox cache. Accordingly, the messaging broker is adapted for efficiently and reliably transferring messages between the OSGi environments. Cache technology can be applied for data transfer in placing a message, comprising a call of a service provided by another OSGi environment into an outbox cache associated with the other OSGi environment: The messaging broker is in this case adapted for transferring the message from the outbox cache associated with the other OSGi environment to an inbox cache of the other OSGi environment. In addition the messaging broker is adapted for notifying the other OSGi environment of the new message in the inbox cache, so that the other OSGi environment can pick up the message and process the service call included therein.
In another aspect, the messaging broker is adapted for sending received messages to a monitoring component, thereby enabling a central recording, analysis and/or replaying of the communication between the plurality of OSGi environments. Accordingly, the messaging broker is in this aspect not just in charge of the data transfer between the OSGi environments, but is also be adapted for sending communicated messages to a monitoring component. This additional feature allows for an analysis and/or even replaying of the communication between the plurality of OSGi environments. Analysis may comprise the information (e.g. comparable to a log) of failed and/or correct communication. Thereby the e.g. failure can be reproduced and repeated.
Certain example embodiments are also related to a system, wherein the functionality of the messaging broker is implemented by a Terracotta cache server (TS), i.e. a server based on the Terracotta products of applicant and/or a server using Java Message Service (JMS), and/or wherein the plurality of OSGi environments communicate using Remote Services for OSGi (R-OSGi). Applicant has found that by using the Terracotta Server of applicant for managing communication the best results are achieved in connection with certain example embodiments in respect to identifying and/or registering and/or limiting OSGi environments. However, the provided messaging broker functionality can be implemented by any suitable server product, cache server and/or technology, such as e.g. JMS. Further, the OSGi environments can be implemented as R-OSGi objects for remote communication.
Further, certain example embodiments provide a method for managing communication between a plurality of Open Services Gateway initiative (OSGi) environments in accordance with any of the above described systems.
Lastly, certain example embodiments also provide a computer program comprising instructions for implementing any of the above described methods.